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(54) Method and apparatus for transparently directing requests for web objects to proxy caches 



(57) In order to transparently redirect an HTTP con- 
nection request that is directed to an origin server (107) 
to a proxy cache (110-1), a proxy redirector (1 04) trans- 
lates the destination address of packets directed to the 
origin sender to the address of the proxy. During a harxi- 
shaking procedure, a TCP connection is transparently 
established between the client (110-1) and the proxy 
cache. When the client transmits a GET request to what 
it thinks is the origin sender, whk;h request specifies the 
complete address of an object at that origin sender that 
it wants a copy of, the proxy redirector modifies the com- 
plete address specified in that GET request before rt is 
sent to the proxy cache. Specifically, the IP address of 
the origin sen/er found in the destinatkjn field in the IP 
header of the one or more packets from the client con- 
taining the GET request is added by the proxy redirector 
as a prefix to the complete URL in the GET request to 
form an absolute URL The proxy cache determines 
from that absolute URL whether it has the requested ob- 
ject stored in its cache. If it does, it sends the object back 
to the proxy redirector, which masquerades those pack- 
ets as coming from the origin server by translating their 
destinatkxi address to the address of the client and their 
source address to that dt the origin server If the proxy 
does not have the requested object, a separate TCP 
connectkxi is established between the proxy and the or- 
igin server from where the object is retrieved and then 
fonivarded over the TCP connection between the client 
and the proxy. In order to account for the additional 
number of bytes in the GET request, an acknowledge- 



ment sequence number in packets returned from the 
proxy that logically foltow receipt of the GET request are 
decremented by that number by the proxy redirector be- 
fore being forwarded to the client. Similarly, a sequence 
number in packets transmitted by the client subsequent 
to the GET request are incremented by that number be- 
fore being forwarded by the proxy redirector to the proxy 
cache. 
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Description 

Reld of the Invention 

s [0001] This invention relates to packet-switched computer networks, and more particularly, to a method and appa- 
ratus in such a network for transparently intercepting client web requests and redirecting them to proxy caches. 

Background of the Invention 

10 [0002] Proxy caching is currently used to decrease tx^h the latency of object retrieval and traffic on the internet 
backbone. As is well known, if a proxy cache has stored a copy of an object from an origin server that has been 
requested by a client, the requested object is supplied to the client from the proxy cache rather than from the origin 
sender. This, therefore, obviates the need to send the request over a wide area network, such as the Internet, to the 
origin sender where the original object Is stored and the responsive transmission of a copy of the requested object back 

IS over the network to the requesting client. 

[0003] Direction of a request from a client to a proxy cache to determine whether a requested copy of an object is 
stored in the cache can be accomplished either transparently or non-transparentty to the client Non-transparent redi- 
rectbn is accomplished through the client's browser program which is configured to send all object requests to a 
designated proxy cache at a specified address. Generally, a browser can be configured to send all of its client requests 

20 to a designated proxy cache if the client is connected on a Local Area Network (LAN), or on an Intranet behind a 
firewall, where a proxy cache associated with that LAN or Intranet is kx:ated. When clients are served by a large Internet 
Sewice ProvkJer (ISP), however, it is not advantageous from the ISP's starKlpoint to allow its subscribers to set their 
browsers to a specifk: proxy cache associated with the ISP. A large ISP likely will have nnany proxy caches in several 
kx:atkxts and will thus want to maintain control over which of its several particular proxy caches a client request is 

2S directed. Further, if a proxy cache whose address is statically set in a client's browser becomes inoperative, all client 
requests will fail. 

[0004] It is therefore nrK>re desirable from an ISP's standpoint with respect to latency and minimizing traffic onto and 
off of the network to transparently intercept a client's web request and send it to one of its operative proxy caches to 
determine whether a copy of the requested object is stored there. If a copy of the requested object is then found to be 

30 stored in that proxy cache, a copy of the object is sent to the client, which is unaware that it has been served an object 
from the proxy cache rather than from the origin server to which it made the request. If the proxy cache does not hold 
a copy of the requested object, then a separate connection is established between the proxy cache and the origin 
sewer to obtain a copy of the object, which when retumed to the proxy is sent to the client over the connection estab- 
lished between the client and the proxy. 

35 [0005] When a client specifies a URL of the object it is requesting a copy of. a Domain Name Sender (DNS) kx>k-up 
is performed to determine from the URL an IP address of an origin sewer which has that requested object As a result 
of that look-up, an IP address is retumed to the client of one of what may be several substantially equivalent servers 
that contain that object. The client then establishes a TCP connection to that server using a three-way handshake 
mechanism. Such a connectkxn is determined at each end by a port number and an IP address. First, a SYN packet 

40 is sent from the client to that origin server, wherein the destination IP address specified in the packet is the DNS- 
determined IP address of the origin sewer and the destination port number for an HTTP request is conventionally port 
80. The source IP address and port number of the packet are the IP address and port number associated with the 
client The client IP address is generally assigned to the client by an ISP and the client port number is dynamk:ally 
assigned by the protocol stack in the client. The origin server then responds back to the client with an ACK SYN packet 

45 In whch the destination IP address and destinatkxi port are the client's IP address and port number and the packet's 
source IP address arKl port number are the server's IP address and the server's port number, the latter generally being 
port 80. After receipt of the ACK SYN packet, the client sends one or more packets to the origin server, which packets 
include a GET request. The GET request includes a complete URL. which klentifies to that sewer the specific object 
within the origin sewer site that the client wants a copy of. Unlike an absolute URL. which includes both site information 

50 (e.g., www.yahoo.com), and object information (e.g., index.html), a complete URL only identifies the particular object 
(e.g., index html) that is requested since the packet(s) containing the GET request is sent to the proper origin sewer 
site by means of the destlnatk>n address of the packet(s). 

[0006] When a browser is configured to non-transparently send all requests to a proxy, a GET request is formulated 
by the browser that includes the absolute URL dt the requested object. That absolute URL is then used by the proxy 
ss to establish a separate TCP connectk)n to the origin sewer if the proxy does not have a copy of the requested object 
in its cache. The proxy requires the absolute URL since the destination address of the packets to the proxy is set by 
the browser to the IP address ol the proxy rather than the IP address of the origin sewer Thus, in order to determine 
whether it has the object in its cache arwJ if not establish a connection to the origin sewer, the proxy requires the 
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absolute URL of the origin server in the GET request 

[0007] When requests are transparently directed to a proxy cache, however, the client browser is unaware that the 
request is being directed to the proxy arid is possibly being fulfilled from the cache. Rather, the client's browser needs 
to think" that it is connected to the origin sen/er to which its SYN and the packet(s) containing the GET request are 

5 addressed. Such origin sender IP address is determined by the browser through a DNS look-up. Further, the source 
address of the ACK SYN packet and the packets containing the requested object must be that same origin sender IP 
address or they will rx>t be recognized by the browser as being the responsive packets to the SYN packet and the 
request tor the object. Thus, in order to transparently send object requests to a proxy cache, a mechanism must be in 
place akyig the packet trartsmissksn path to intercept an initial SYN packet sent by a browser and to redirect it to the 

10 proxy cache to establish a TCP connectkxi. The proxy cache must then masquerade as the origin sender when sending 
the ACK SYN packet back to the client by using the origin sender's IP address and port number as the source address 
of that packet. Further, the subsequent packet(s) containing a GET request must be redirected to the proxy cache and 
the request fulfilled either from the cache or via a separate TCP connection from the proxy to the origin sen/er In either 
case, the source address of packets sent back to the client must be the origin sender's I P address and port number to 

15 which the packets sent by the client are addressed. 

[0008] In order for packets associated with a request for an object to be redirected to a proxy cache connected 
somewhere in the r^etwork, a Layer 4 (L4) switch on the packet path "kx)ks' at the port number of a destination address 
of a SYN request packet Since HTTP connectnn requests are generally directed to port 80 of an origin server, the L4 
switch transparently redirects all packets having a port number of 80 in the destinatbn address. The SYN packet is 

20 thus sent to a selected proxy cache. In order for the proxy cache to property respond to the client, as noted, it must 
know the absolute URL of the requested object arKi packets returned to the client must masquerade as coming from 
the origin sender Unlike the non-trar^sparent caching method previously described in whbh the browser formulates a 
GET request with the absolute URL, for transparent caching the absolute URL must be provkJed in some manner to 
the proxy cache in order for the proxy to determine whether it in fact has the requested object in its cache, or whether 

25 it must establish a separate TCP connecton to the origin sender to request the object. In the prior art. when one or 
nrK>re caches are directly connected to the L4 switch, the switch chooses one dt the caches and transparently f onwards 
the packets to that proxy without nrxxJifying the source or destinatksn address of the packets. The proxy working in a 
promiscuous TCP mode accepts all incoming packets regardless of their destinatbn address. The proxy then receiving 
the SYN packet with the origin server's destination address and the client's source address, can respond to SYN packet 

00 with an ACK SYN packet. This ACK SYN packet has the client's address as a destination address and a source address 
masquerading as the origin sen/er address. This packet is transported through the L4 switch onto the network over 
the TCP connection back to the client The subsequent packet(s) with the GET request from the client is redirected by 
the L4 switch to the directly connected proxy. Since the GET packet(s) only contains the complete URL, the proxy must 
formulate the absolute URL to determine whether its has the requested object in its cache or whether is must establish 

3S a separate TCP connectkxi to the origin sen/er. The proxy forms the absolute URL by prefixing the complete URL in 
the GET request with the IP address dt the origin sen/er in the destination address of the packet. The proxy can then 
determine whether it has the object and, if not, establish a TCP connection to that absolute address. If that particular 
origin sen/er at that IP address shouM be inoperative, the proxy can alternatively prefix the complete URL in the GET 
request with the k>gical name of the site irwikated in the HOST field in the packet(s) containing the GET request. 

^ [0009] In the prior art, if the proxy cache is not directly connected to the L4 switch, then the L4 switch must perform 
a network address translatran (NAT) arul port address translation (PAT) on those packets directed to port 80 of an origin 
sen/er. Specifically, when the L4 switch receives a SYN packet to initiate a TCP connection from a client to an origin 
sen/er, it trar^tes the destinatkxi address of the packet from the IP address and port number of the origin sen/er to 
the IP address and port nunnber of a selected proxy cache. Further, the switch translates the source address of the 

45 packet from the clients I P address and port number to its own I P address and a port number When the proxy responds 
with an ACK SYN packet, it therefore responds to the L4 switch where a NAT translates the destinatk>n IP address 
from the IP address of the L4 switch to the IP address of the client, and translates the source IP address from the IP 
address of the proxy to IP address of the origin sen/er A PAT also translates the port number in the destination address 
from that of the L4 switch to that of the client, and translates the port number in the source address from that of the 

so proxy to that of the origin sen/er (usually 80). When the client sends an ACK packet and then the packet(s) containing 
the GET request to the origin sen/er. the L4 switch again performs a NAT, translating the destination IP address to the 
IP address of the proxy. Thus, when the packet(s) containing the GET request is received by the proxy, it does not 
know the IP address df the origin server as in the directly connected proxy arrangement described above. The proxy 
must therefore look at the k)gk:ai name in the HOST fiekl and perform a DNS kx>k-up to determine that site's I P address. 

ss The proxy then uses that IP address in combinatkxi with the complete URL in the GET request to form an absolute 
URL from whrch it determines whether it has the requested object in its cache. If it doesnl, a separate TCP connection 
is established from the proxy to that absolute URL to.retrieve that object, which is retumed to the proxy Whether the 
object is found in the proxy cache or is retrieved over the separate connection from the origin server, it is fonwarded 
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back to the L4 switch where a NAT and PAT are performed to translate the destination address to that of the client and 
to translate the source address to the particular ongtn server to which the client's request was directed. It should t>e 
noted that the source address of the origin server obtained when the client's browser initiates a DNS look-up using the 
origin server's absolute URL may not be the same IP address obtained when the proxy performs a DNS look-up using 

s the combinatnn of the site URL in the HOST fieki and the complete URL in the GET request 

[001 OJ The above described technques for performing transparent proxy caching have several disadvantages. First- 
ly, use of a HOST fieki to specify a logk:al name of an origin sen/er ts not currently trKX>rporated within the presently 
emptoyed HTTP1.0 sterKiards. Thus, a HOST field may not be present in the packet(s) containing a GET request. 
Where, as described above, the information in the hKDST fieki is necessary to form an absolute URL to determine 

10 whether the proxy cache has the requested object arKt, if not, to establish a connection to an origin server from the 
proxy, the absence of the HOST field results in an unfilled request. Secondly, the prior art techniques require the proxy 
cache to perfonm the functk)n of forming an absolute URL from the information in the HOST fieW and in the packet(s) 
containing the GET request. Thus, standard proxy caches which expect the client's browser to produce the absolute 
URL cannot be used. A methodok)gy for transparent proxy caching that is transparent to both the client and the proxy 

IS is desirable to avoid rrKxiificatbn to the program that controls proxy cache operatbns. Standard proxy caches couki 
thus be employed anywhere in the network without the need for a special implementation. 

[001 1] The above descrfbed prior art techn k)ues have even further disadvantages with respect to persistent connec- 
tk>ns defined by the HTTP1.1 standards. As defined by these standards, a persistent connection enables a client to 
send plural GET requests over the same TCP connectbn once that connectkvi has been established between two 

20 endpoints. When a prior art transparent proxy cache is interposed on the conneclton. a client may think' it has estab- 
lished a persistent connectkxi to the specific origin server determined through the DNS look-up. The connection in 
reality, however, is transparently diverted by the L4 switch to a proxy cache. The proxy cache, in response to a DNS 
kx>k-up using the k)gica] name in the HOST fieki, may be directed to an equivalent origin sender at a different IP address. 
Further, as each subsequent GET request is received by the proxy from the client within the client's perceived persistent 

25 connedkxi, each responsive DNS look-up to the logical name may direct a connection to an even different IP address 
of an equivalent origin server. As a result, the advantages of a transacton^riented persistent connection in which a 
server is capable of maintaining state infonmatkyi throughout the connection, are lost A methodology is desirable that 
maintains persistence to the same origin sender to whfch the clients browser is directed, or to a same equivalent origin 
sender throughout the duration of the persistent connection. 

30 

Summary of the Invention 

[0012] The problems associated with the prbr art technkjues for transparent proxy caching are eliminated by the 
present inventkm. In accordance with the present inventkxi, a switching entity, such as the L4 switch (referred to 

3S hereinafter as a proxy redirector), through which the packets flow; is provkied with the funclk>nalities at the IP level 
necessary to transform the complete URL in each GET request transmitted by a client to an appropriate absolute URL. 
Specifically, the IP address found in the destinatkwi fieki in the IP header of the packet(s) from the client containing 
the GET request are added as a prefix by the proxy redirector to the complete URL in the GET request. As a result, 
the complete URL in the GET request is nrKxlified to form an absolute URL which, when received by the proxy cache. 

40 is directly used to determine if the requested object is stored in the cache and, if not, to establish a separate TCP 
connectbn to the origin sender The GET request received by the proxy is thus equivalent to what it wouW expect to 
receive if it were operating in the non-transparent mode. Advantageously, if a persistent connectkxi is established, 
each subsequent GET request has the same IP address prefix determined by the initial DNS look-up by the client. 
[0013] By modifying the GET request at the proxy redirector to include the destinatk)n address of the origin sender, 

45 the number of bytes at the IP level in the packet containing the resultant absolute address are increased by the number 
of bytes in the prefix. Included in the header within each packet is a sequence number (seq) that provkies an indication 
of the positbn of the first byte number in the payk>ad. Thus, when the IP address is added to a packet, the sequence 
number of each of the subsequent packets needs to be incremented by the count of the added bytes. Further, an 
ackrtowledgement sequence number (ack_seq) in the header on the packets retumed from the proxy or the origin 

50 server that togically follow receipt of the GET packet(s) at the origin sender needs to be decremented by the proxy 
redirector before being forwarded to the client to avoki confusing the client with respect to what the sequence number 
of the next byte it sends should be. Further, if the GET request sent by the client encompasses more than one TCP 
segment, then the extra bytes in the first of the segments caused by the additkxial bytes added to the URL are shifted 
into the second segment, and the resultant now extra bytes in the second segment are shifted into the third segment, 

ss etc., until the last of the segments. In order to preclude the necessity of requiring an extra segment to be added to the 
GET request to accomnxxlate the extra bytes, the client sending the GET request is deceived into sending segments 
whose maximum size is less than what can actually be received by the proxy as indicated by a maximum segment 
size (MSS) field in packets from the proxy. The proxy redirector, upon receipt of the ACK SYN packet from the proxy, 
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reduces the MSS parameter received from the proxy by the amount of the number of bytes that will be added to the 
GET request before that parameter is forwarded to the client Thus, when the client next sends a GET request, each 
segment is limited to the reduced MSS, thereby insuring that the segment size of a last segment in a GET request 
after the IP address is prefixed by the proxy redirector to form the absolute URL (whether the GET request is one or 
s more segments long) is less tfian or equal to the actual MSS that the proxy can receive. 

Brief Description of the Drawing 

[0014] 

TO 

FIG. 1 is a block diagram of a network that includes a proxy redirector that transparently sends requests from a 
client to a proxy cache by changing the destination address of packets in a client request from that of the origin 
server to that of a proxy and the source address from that of the client to that of the switching entity and, in ac- 
cordance with the present invention, rrKxJifies a GET request to include the destinaton address of the origin server; 
IS FIG. 2 is a block diagram showing the proxy redirector implemented on a programmable network element that 

manipulates packets in accordance with ir^tructions provided by a loaded program; arKi 
FIG. 3, 4, 5 and 6 are flow charts detailing the operation of the proxy redirector. 

Detailed Description 

20 

[0015] With reference to FIG. 1. a plurality of clients 101-1 - 1 01 -N are connected to a kx»l area network (LAN) 102, 
such as an Ethernet IAN 102, whk:h, in turn, is connected through a router 103 to a Level 4 (L4) switch 104 (proxy 
redirector) whk^ interfaces the LAN with a wkJe area network (WAN) 105, such as the Internet Although shown as 
two separate elements, the functionalities of router 103 and proxy redirector 104 can in actual practice be combined 

2S in a SBTigle unit. All requests from any of the clients connected to LAN 102 for objects stored in servers connected to 
the Intemet 105 traverse proxy redirector 104 onto the Internet. The packets comprising such requests, which include 
the standardized packets that establish a TCP conneclron. are directed to an IP destinatton address and port number 
indicated in the IP header of each packet originating from a client source address that includes a client IP address and 
port number. Similarly, responses to such requests from an origin server connected to Internet 105 are directed via an 

30 IP destinatran address that is equal to the client's IP address and port number from which the request originated, and 
have as a source address the server's IP address and port number All such packets directed to any of the clients 
101-1 - 101-N from any server connected to Intemet 105 pass through proxy redirector 104. 

[0016] When any of the clients connected to LAN 102, such as client 101 -1 , makes a request through a browser for 
an object by specifying a logical URL, a domain name sewer (DNS) 1 06 connected kxally or on Intemet 1 05, as shown, 

3S is accessed to perform a datak>ase look-up based on that togical.name. An associated IP address is then returned to 
the browser. The IP address returned to the browser is the IP address of a partrcular origin sen/er which contains the 
object requested through the logical URL Since a togrcal name may in fact be associated with a plurality of essentially 
equivalent origin servers, such as servers 107 and 109, the particular IP address returned to the client browser chosen 
by DNS 106 may be determined in a round-robin manner. When DNS 106 selects an origin server corresponding to 

40 the iogtca\ URL. the IP address of the selected origin sender, such as, for example, the IP address of origin sender 1 07, 
is returned to the browser in the requesting client 101-1. That IP address then senses as the IP address to which 
packets directed to the origin sewer from the client are directed. Conventionally, http requests are usually directed to 
port BO of an origin server. 

[0017] With the IP address of the origin server determined and returned to the client, the browser establishes a TCP 
45 connection between the client artd the origin sender through a three-way handshaking process. Specifically, a SYN 
packet, addressed to the I P address of the selected origin server, is sent by the client Handshaking is completed when 
the client receives an acknowledgement of receipt of that SYN packet through an ACK SYN packet sent by that origin 
sender, and responds with a ACK packet to the origin server. The browser then sends a GET request that specifies the 
partbular requested object. 

so [001 8] In accordance with the present inventkxi, once the IP acWress of the origin server corresponding to the logical 
URL name is determined through the DNS kx>k-up. proxy redirector 104, rather than establishing a TCP connection 
to the origin server at the determined IP address, transparently establishes a TCP connectbn between the client and 
a proxy. If the requested object is stored in the cache, a copy of that object is transparently retumed to the requesting 
client. A TCP connectkxt, therefore, is not established over the Intemet 105, to the actual origin sewer 107 to provide 

55 the requested object to the requesting client. The coss of transmitting the request to the origin server over the Intemet 
and transmitting the copy of the requested object back over the Intemet are thereby saved in addition to the time 
required for transmitting such a request over the Intemet and waiting for a response from the origin server If the proxy 
cache to whbh the request is directed does not contain the requested object, a separate TCP connectk>n is established 
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between the proxy cache and the origin server to obtain a copy of the requested object. When the proxy cache then 
receives thscopy of the requested object from an origin sender overthat separate TCP connection, the copy is f onvarded 
to the client over the original TCP connection that was established between the client and the proxy cache. 
[001 9] I n the ennbodiment shown in Ft G. 1 , a proxy cache 11 0-1 is illustratively shown connected to a LAN 1 1 1 , wh ich 

5 is connected to LAN 102 through a router 112. Another proxy cache 115 is shown connected on a different LAN 116 
through router 1 03. Other proxy caches can be located anywhere on LANs 1 02, 1 1 1 , or 1 1 6, on arK>ther LAN connected 
to the Internet 105 such as proxy cache 117. Proxy redirector 104 selects one of the available proxy caches to which 
to forward client requests based on a metric such as least-loaded or round-robin, based on IP header information such 
as the origin sen/er IP address. With respect to the tatter, all objects from a specific origin server will be served by a 

10 specific proxy. 

[0020] In the preferred embodiment descn'bed herein, proxy redirector 1 04 includes a programmable network element 
of the type described in copendrtg U.S. patent application Serial Number 09/1 90,355, filed November 12, 1998, which 
application is incorporated herein by reference. As described in that application, that programmable network element 
in the preferred enntxxjiment runs on a Linux machine. As shown in FIG. 2, the programmable network element 200 

IS includes a dispatcher process 202 with which plural different gateway programs (204, 205 and 206) register and request 
access to IP packets that fit specifk: descriptions. Such programs are loaded through an admission daenrxxi 210 via a 
local program injector 211 or a remote program injector 212. A gateway program, for example, can request access to 
incoming packets to network interface 208 that match certain source and destinatkxi IP address ranges and port nunrv 
bers. The dispatcher process 202 uses a packet fitter 203 in the Linux kernel 201 to obtain packets requested by the 

20 gateway programs and uses a raw IP socket 21 5 to send packets that have been manipulated in accordance with the 
gateway program t>ack to the kernel for output back to the network through filter 203 through network interfaces 208. 
Library f unctkxis are provided in the programmable network element that enable a gateway program to communicate 
with the dispatcher process 202 to register rules that specify the type of IP packets tfiat a gateway program wants 
diverted to it. A gateway program can request either a complete IP packet or only the IP and TCP header of a packet 

2S and can change both the header and payload of a packet 

[0021] In the present inventkxi, that programmable network element is operative in combinatkxi with a gateway 
program that manipulates the destination and source addresses of packets flowing there through in a nnanner to be 
described, as well as modifying, as will be described, information in the packet(s) containing the GET request that 
specifies the URL of the requested object. Specifically, the programmable network element in combination with the 

30 gateway program operates on packets associated with HTTP requests, which are determined from the destination port 
number. As prevk>usly noted, HTTP requests are conventionally addressed to port 80 of an origin server. Thus, the 
prograrrvnable network element/gateway program which together comprise proxy redirector 104 in this emtxxJiment, 
captures through the dispatcher process of the programmable network element, packets directed to port 80 and then 
performs address translatkxis on those captured packets to readdress these packets to a selected proxy. With respect 

35 to address translations, the gateway program translates the destination I P address of packets addressed to the origin 
server to the IP address of a selected proxy cache and translates the source IP address of such packete from that of 
the client to the IP address of proxy redirector 104. Further, in order for proxy redirector 104 to identify requests from 
plural client terminals that are directed to the same proxy, the source port number is translated to a bogus ghost port 
number at the proxy redirector. Thus, when proxy cache responds, the packets transmitted by the cache have a des- 

40 tination IP address of proxy redirector 1 04 at that bogus port number, which is distinctly associated with the client The 
gateway program within proxy redirector 104 then translates the IP destination address of these responsive packets 
from the proxy to the IP address of the client and translates the t)ogus destination port number to the port number from 
which the client originated its request. Further, the gateway program translates the source IP address of such respon- 
sive packets from that of the proxy to the IP address of the origin server and the port number to the port (80) to which 

45 the client's requests were originally directed. Thus, the packets whrch are returned to the client from the proxy mas- 
querade as if they had originated from the origin server to whk:h the client "believed' its request had been sent 
[0022] By performing the above-described network address translations (NATs) and port address translations (PATs), 
packets from a client 101-1 are transparently directed by proxy redirector 104 to a proxy cache. Responsive packets 
from the proxy cache are sent to proxy redirector 104 where they are redirected to client 101 -1 . 

so [0023] In establishing a TCP connection that is directed to an origin sender, client 1 01 -1 first transmits a SYN packet, 
which is intercepted by proxy redirector 104. Proxy redirector 104 selects a proxy cache, such as proxy 110-1, to 
redirect this request and creates a connectk>n control block (CCB) to maintain information about the connection. Se- 
lection of the particular proxy is determined, as described above, by one of several possible algorithms. The CCB is 
used to store the client IP address and TCP port number and the origin sen/er IP address and TCP port number, both 

55 of which are contained in the IP header of the SYN packet, and the chosen proxy's IP address. The destination address 
is then changed to that of the chosen proxy arKi the packet is sent back to the network for redirectkxi to its new 
destir^tion address of the proxy 110-1 . All subsequent packets that originate from the same client with the same TCP 
port number are then fonwarded to the same proxy. Proxy 110-1 responds with an ACK SYN packet which is directed 
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via its destination address to proxy redirector 110-1. Proxy redirector 104 then translates the source IP address and 
port numt)8r to those erf the origin server and the destination IP address and port number to those of the client. When 
the packet arrives at the client the client believes that it is connected to the origin server The client then responds with 
an ACK packet to the origin server, which is redirected by proxy redirector 104 to proxy cache 110-1 , to complete the 
B handshaking process. 

[0Q24] After the TCP connection is established between client 101-1 and proxy cache 110-1, client 101-1 sends one 
or more packets containing a GET request addressed to the origin sewer. Such packets are thus "captured" by proxy 
redirector 1 04 and redirected to proxy cache 1 1 0-1 . As previously discussed, the G ET request sent by the client contains 
only the complete URL sent by the client browser which in itself provides insufficient information for the proxy cache 

to to detenmine whether it has the requested object and, rf not, to forward it to the origin serve,r which does. In accordance 
with the present inventkxi. the ^eway program that is operative with the programmable network element of the proxy 
redirector 1 04, captures this packet or packets and, in addition to previously described address translattons, transforms 
the complete URL to an absolute URL by prefixing it with the IP address of the origin sender obtained from the destinatbn 
IP address erf the packet(s) containing the GET request. Thus, Level 7 (application) information is modified to assist 

^5 in level 4 routirtg. 

p)025] In order to make the URL transformaton transparent to both the client and proxy cache endpotnts, changes 
in IP and TCP headers are also required. Since the GET request modificatton increases the length of the IP packet 
that carries the GET request, the total length field on the IP header of this packet is increased by an offset. The offset 
amount is recorded in the CCB. In addition, the TCP header contains sequence numbers (seq) and acknowledgement 

20 sequence numbers (ackjseq) that need to be translated. The seq in the TCP header Indicates the byte number of the 
first byte on this packet going from the sender to the receiver ewer the TCP session and the ack_seq indicates the byte 
number of the next byte that the sender expects to receive from the receiver. For all packets after the GET packet(s) 
that go from the client to the proxy cache, the seq is increased by an offset equal to the fengf/)o/(absolute URL) - 
/o/^/)or{complete URL) so that the seq matches the byte number <rf the byte that the proxy cache expects to receive 

2S from the client. Similarly, on all packets starting with the acknowledgement to the GET packet that go from the proxy 
cache to the client through the proxy redirector. the ack_seq is decreased by the same offset so that the ack_seq 
matches the byte number of the byte that the proxy cache woukJ expect the client to send in the next packet foltowing 
the GET packet. By performing these changes in the header, the client and proxy cache endpoints remain unaware of 
the modiftt^ation in the GET packets from the complete URL to the absolute URL 

30 [0026] Table 1 illustrates the URL and other header transformatk>ns performed 
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Table 1 



Arriving packet 



— > beginning of packet header dump <— 

— > IP header version=4 hdrjen=5 TOS=0 pktjen=346 id=60276 

frag_off^OOOH TTL=64 protocol=6 ck$um=1792H 

saddr=135.104.25.243 daddr=204.71. 200.244 
— > TCP header sport=1273 dport=80 seq=21 89084427 
ack_seq=3266449517 

tcp_hdrjen=5 flags=ACK PSH 

res1=0H res2^)H window=31856 cksum=162H urgent=0 
— > beginning of packet data dump <— 
GET /a/ya/yahoomaiI/promo1 .grf HTTP/1 .0 
Referer http7Avww.yahoo.com/ 
Connection: Keep-Alive 

User-Agent Mo2illa/4.05 [en] (XII; U; Unux 2.1.103 i686) 
Host us.yimg.com 

Accept image/gif, image/x-xbitmap, image/jpeg, image/pjpeg image/png 
Accept-Language: en 
Accept-Charset iso-8859-1 .*,utf-8 

Modified to: 
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— > beginning of packet header dump <— 

— > IP header version=4 hdrjen=5 TOS=0 pktjen=367 id=60276 

frag_ofP=4000H TTL=64 protocol=6 cksum=1792H 

saddr=1 35.104.25.245 daddr=1 35.1 04.25.31 
— > TCP header sport=5000 dport=7000 seq=2 189084427 
ack_seq=3266449517 

tcp_hdrjen=5 flags=ACK PSH 

res1=0H res2=0H window=31856 cksum=162H urgent=0 
— > beginning of packet data dump < — 
GET http://204.71 .200.244/a/ya/yahoomail/promo1.gif HTTP/1.0 
Referen http://www.yahoo.com/ 
Connection: Keep-Alive 

User-Agent Moziila/4.05 [en] (XII; U; Linux 2.1.103 1686) 
Host us.yimg.com 

Accept image/gif« image^-xbitmap, image/jpeg, image/pjpeg image/png 
Accept-Language: en 
Accept-Charset tso-8859-1 ,*,utf-8 



on a GET packet that arrives at proxy redirector 104 from a client 101 -1 . The packet is destined to an origin server at 
a destination IP address (daddr) 204,71.200.244 (www.yahoo.com) at a destination port (dport) 80, requesting object 
/a/ya/yahoomail/promol.gif. As can be noted in the modified packet, the packet is redirected to a proxy cache 110-1 
at IP address 135. 104.25.31 port 70(K) by changing the daddr and dport header informatkxi. Also, the complete URL 
of the object in the GET request is modified in the translated packet by prefixing it with hnpJ/204. 71.200.244 to fonm 
the absolute URL, where that prefix is obtained from the daddr header in the arriving packet. This transformation 
increases the length of the packet by 21 bytes so that the pkljen field in the header is modified from 346 to 367 bytes. 
Further, the source port is nrxxlified to a bogus port number by changing sport to 5000. 

[0Q27] Table 2 shows the translatkxis perfonmed by the proxy redirector 1 04 to an acknowledgment from proxy cache 
110-1 to the GET request. The arriving 
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Table 2 



Arriving packet: 



— > beginning of packet header dump < — 

— > IP header version=4 hdrjen=5 TOS=0 pktjen=40 id=14559 

frag_off=4000H TTL=255 protocoNG cksum=10eH 

saddr=1 35. 1 04.25.31 daddr=1 35. 1 04.25.245 
— > TCP header sport=7000 dport=5000 seq=3266449517 
ack_seq=2189084754 

tcp_hdrjen=5 flags^ACK 

res1=0H res2^H window=8433 cksum=32H urgent=0 
Modified to: 



— > beginning of packet header dump < — 

— > IP header version=4 hdrjen=5 TOS=0 pktjen=40 id=14559 
frag_ofF=4000H TTL=255 protocol=6 cksum=10eH 
saddr=204.71 .200.244 daddp=1 35. 1 04.25.243 

— > TCP header sport=80 dport=1273 seq=3266449517 

ack_seq=2189084733 
tcp_hdrjen=5 flags=ACK 

res1=0H res2=0H window=8433 cksum=32H urgent=0 



packet is addressed (daddr) to the IP address of the proxy redirector at the bogus port (dport) 5000 used by the proxy 
redirector for this TCP connection. The source IP address (saddr) and the source port (sport) are those of the proxy 
cache to where the GET request was directed. The ack_seq fieki indicates the byte number of the first byte that is 
expected to be sent in the packet folbwing the GET packet. In this exarrtple, ack_seq is equal to the sequence number 
(seq) 218908427 the GET packet plus the length of the GET packet, which in this case per Table 1 is 367. Thus 
ack_seq of the arriving packet is 218908754. Since client 101-1 is unaware that a proxy redirector has increased the 
length dS the GET packet by 21 bytes, proxy redirector 1 04 decreases the ack.seq field by the number of bytes added, 
21 . Further, proxy redirector 104 translates the destination IP address and port number to those of the client 101-1 , 
and the source IP address and port number to that of the origin sen/er The nrKxJified packet, when received by the 
client, thus appears to the client to have originated from the origin server and the ack_seq field indk:ates a byte number 
that the client would next expect to send having previously sent a packet of length 367 bytes. All packets that are 
subsequently sent through the proxy redirector 104 to client 101-1 from proxy cache 110-1 are similarly modified to 
decrement the ack_seq fieki by the number of bytes, 21 , added to the GET packet. 

[0028] Table 3 illustrates a next packet sent by client 101 -1 to the origin sen/er after the GET packet. In this packet 
the sequer^ce number (seq) is equal to the modified ack_seq sent to the client, as per Table 2. The destination IP 
address and port number are those of the origin server and the source IP address and port number are those of the 
client. When received by proxy redirector 1 04, the packet ts modified to change the source IP address and port number 
to the IP address and bogus port number of the proxy redirector The destinatkxi address IP and port number are 
translated to that of proxy cache 110-1. The sequence number (seq) is increased by that same value of 21 to match 
the byte number that the proxy cache expects to receive based on the sequence number previously received in the 



10 



EP1011244A2 

GET packet and the length, 367, o* the GET packet 

Table 3 



Arriving packet: 



— > beginning of packet header dump <— 

— > IP header version=4 hdrjen=5 TOS=0 pkt_len=40 id=60281 
frag_off=4000H TTL=64 protocol=6 cksum=18bfH 
saddr=1 35. 1 04.25.243 daddr=204,71 .200.244 

— > TCP header sport=1273 dport=80 seq=21 89084733 

ack_seq=3266450977 
tcp_hdrjen=5 fiags^ACK 

res1=0H res2=0H window=31856 cksum=d3f7H urgent=0 
Modified to: 



— > beginning of packet header dump <— 

— > IP header version=4 hdrjen=5 TOS=0 pktjen=40 id=60281 

frag_off=4000H TTL=64 protocol=6 cksum=18bfH 

saddr=1 35. 1 04.25.245 daddr=1 35. 1 04.25.31 
— > TCP header sport=5000 dport=7000 seq=21 89084754 
ack_seq=3266450977 

tcp_hdrjen=5 flags=ACK 

res1=0H res2-0H window=31856 cksum=d3f7H urgent=0 



received. All subsequent packets directed to the origin server from client 101-1 are similarly modified before being 
directed to proxy cache 110-1. 

[0029] In the above-description, rt has been assumed that the length of the GET request both before modiftcatkxi, 
and after the URL extenskm is less than the maximum TCP segment size. In fact, the length of the GET request may 
be kyiger than one TCP segment If the length of the GET request carrying the complete URL occupies x number of 
TCP segment and, after it is modified to carry the absolute URL, it still also fits into that same x number of TCP segments, 
then the segment carrying the URL is modified and overfk>wing characters are pipelined from one segment to the next. 
Thus, the overflowing characters from a previous packet are prefixed to the start of the next packet, etc., until the last 
packet, which length is increased by the increased number of bytes due to the URL modification. Therefore, the packet 
length of only the last segment is modified to include the characters that have been shifted into that segment. The 
ack_seq parameter in packets from the proxy cache to the client is modified starting from the acknowledgment to the 
last GET packet. 

[0030] If the modification of the URL to the absolute URL could cause the last TCP segment of the GET request to 
overflow to another segment, a new TCP segment wouU need to be constructed and injected by the proxy redirector. 
The proxy redirector woukJ then need to have the capability to retransmit this segment if it was k>st. Thus, the proxy 
redirector would need to have some TCP layer functionalities. In order to avoid adding higher level functionality to the 
proxy redirector, segment sizes are limited to less than wfiat the proxy cache is actually capable of receiving. When 
the complete URL is transformed to an extended URL, the maximum increase in size is 22 bytes, equal to the maximum 
length of an IP address of 1 5 bytes plus 7 bytes from the prefix: httpy/. The client is deceived to send segments whose 
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maximum size is 22 bytes less than what the protocol allows it to send. The TCP segment size sent by the client is 
detemnined by what the proxy cache, in its handshake with the client, indicates as the maximum segment size it can 
receive. This is indicates by the proxy cache through the maximum segment size (MSS) field in the ACK SYN packet 
Accordingly, the proxy redirector 104 intercepts the ACK SYN packets and decreases the specified MSS amount by 

s 22. For example, if the MSS specified by the proxy cache is 14G0, it is modified to 1438 by the proxy redirector before 
being sent to the client When the client next sends a GET request, the TCP segments are limited to 1438 bytes. In 
the worst case, when the client sends a GET request, 22 bytes will be added to the xth TCP segment that carries this 
request. The length of this xth TCP segment will still then be within the maximum length specified by the proxy cache. 
If the event that the proxy cache does not stipulate a maximum MSS in the ACK SYN packet, the default used by the 

10 client is 536 bytes. An MSS optkxi is then added by the proxy redirector to inform the client that the maximum MSS 
expected by the other end of the TCP connectkxi is 514 bytes. 

[0031] As previously described, a NAT and PAT are performed by proxy redirector 104 on all packets addressed by 
client 101-1 to an origin server, and all packets addressed by proxy cache 110-1 to proxy redirector 104 for return to 
the client. Proxy redirector 104 thus performs a NAT an6 a PAT on these packets flowing in both direction. If proxy 

IS redirector 1 04 selects a proxy cache that is located in such a point on the network that packets from the proxy cache 
addressed directly to client 1 01 -1 must pass through proocy redirector 1 04 due to the network configuration, then proxy 
redirector need only perform a half-NAT on the packets fkywing through it. Specifically, if proxy redirector 104 selects 
a proxy cache such as proxy cache 11 7, all packets addressed to client 1 01 -1 must pass through proxy redirector 1 04. 
Proxy redirector 104 thus only needs to transform the destinatkxi IP address and port number of packets from client 

20 101 -1 to the IP address and port numt>er of proxy cache 117, while maintaining the source IP address and port number 
as those of client 101-1 . The packets retumed from proxy cache 117 will thus be addressed to the client's IP address 
and port number. When they pass through proxy redirector 104. they are captured and the transformatkx) of the source 
IP address and port to those of the origin server are the only address changes that need to be effected. 
[0032] The problems of the prior art with respect to persistent connections is obviated in accordance with the present 

25 inventbn. As prevbusly noted, during a persistent connection plural GET requests can be made by a client In the 
prior art. as described, each GET request can result in a connection from a proxy cache to a different origin sender if 
the proxy cache does not have the requested objects. The ability of a sender to maintain the state of a client's connection 
throughout the duration of the connection is compromised if each GET request results in connections to multiple servers. 
In accordance with the present inventkx), once the IP address of the origin sender is determined at the initial DNS 

30 kx>kup, that same IP address is used by the proxy redirector as a prefix to each complete URL in every GET request 
issued by the client throughout the duration of the persistent connection. Thus, assuming the proxy cache does not 
contain any of the requested objects, the proxy cache will establish a TCP connection to the same origin sender in 
response to each GET request generated by the client It should be noted that if plural client GET requests are foPA/arded 
by the proxy redirector to a proxy cache within a persistent TCP connection. ack_seq parameter in packets that flow 

35 through the proxy redirector from the proxy following each GET request must reflect the cumulative changes effected 
by trartslating the complete URL to the absolute URL in each of the preceding GET requests within the same TCP 
connectkyi. Similarty. in all packets received by the proocy redirector from the client directed to the origin sender within 
a persistent TCP cormectkxY, the seq parameter must reflect cumulative changes. 

[0033] FIGS. 3. and 4. together are flow charts detailing the functions of proxy redirector 1 04 in establishing a TCP 

40 connectk>n to a proxy cache and rrxxiifying the GET request so that such requests can be transparently fon^^arded to 
the proxy. At step 301 . a SYN packet arrives from the client at the proxy redirector At step 302, proxy redirector selects 
a proxy cache based on a load batarK:ing algorithm or on an arbitrary or random selection. At step 303, proxy redirector 
performs a full NAT, changing the daddr from that of the origin server to that of the selected proxy and saddr from that 
of the client to thaX of the proxy redirector. At step 304 a PAT is performed, changing sport to that of a bogus ghost port 

45 number and dport to the proxy's port number. At step 305. the SYN packet is sent to the proxy. In response to that 
SYN packet, the proxy responds, at step 306, with a SYN ACK packet containing an MSS parameter in the TCP header. 
At step 307, a reverse translation is performed on both the IP addresses and port numbers, changing saddr and sport 
to those of the origin server and daddr and dport to those of the client At step 308. the MSS field is changed by reducing 
the value of the MSS received from the proxy by 22. At step 309, the ACK SYN packet is sent to the client At step 

so 31 0. proxy redirector receives a responsive ACK packet from the client At step 311 . a full NAT and PAT are performed 
on that packet and. at step 312. the rrKxjrfied packet is sent to the proxy, thereby completing the handshake sequence. 
[0034] At step 313. a packet containing a GET request is received from the client A full NAT is performed at step 
31 4 and a PAT is performed at step 31 5. A determination is made at deciskxi step 31 6 whether this is a first packet in 
the GET request If yes, at step 317, the IP address of the origin sewer obtained from daddr of the arriving packet is 

ss prefixed to the complete URL in the GET request. If, at step 316, the packet is not a first packet in a GET request, 
then, at step 318. the overflow bytes from the previous GET packet are prefixed to those bytes in the cunent packet 
and if the total number of bytes in the resultant packet is than the actual MSS sent by the proxy, the overflow bytes 
greater are buffered for prefixing to the next packet After alternative steps 316 or 318. at step 319, a determinatk)n is 
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made whether the current packet is the last packet a GET request If not, at step 320, the current packet Is sent to 
the proxy and the flow retunns to step 31 3 to receive the next packet in the GET request from the client. If at step 31 9, 
the current packet is the last packet in a GET message, then, at step 321. the pktjen parameter of that packet is 
changed to reflect the change in length of the packet. At step 322, the modified packet is sent to the proxy. 

5 [0035] FIG. 5 illustrates the steps performed by the proxy redirector for each packet received from the proxy starting 
from the ACK to the GET request through the end of the connection. At step 501. the proxy redirector receives the 
ACK to the GET request, or any other packet that togically foltows the ACK to the GET request. At step 502, reverse 
NAT and PATs are performed, translating daddr arwJ dport to those of the client and saddr and sport to those of the 
origin server At step 503, ack_seq is decreased by the amount added in the preceding GET request. At step 504. the 

10 riKxlified packet is sent to the client 

[0036] FIG. 6 illustrates the step performed by the proxy redirector for each packet destined for the origin server 
from the client that follows the GET request At step 601. a packet subsequent to the GET request is received from 
the client At step 602. a full NAT and PAT are performed. At step 603, seq_no is increased by the amount of bytes 
added by modifying the previous GET request At step 604, the packet is sent to the proxy. 

IS [0037] In the discussion above of RGS. 3, 4, 5 and 6, it has been assumed that the proxy cache is kjcated in a 
positk)n such that packets directed to the client will not automatically flow through the proxy redirector Tlius, all packets 
from the proxy are addressed to the proxy redirector. Therefore, for packets flowing from the client, and packets flowing 
from the proxy, the proxy redirector performs a full NAT and PAT If however, as previously described, the proxy cache 
selected by the proxy redirector is located on the network so that all packets from proxy to the client automatically flow 

20 through the proxy redirector, then, in the steps shown in RGS. 3, 4. 5 and 6, only a half NAT needs to be performed. 
[0038] Although described in conjunction the programmable network element shown in FIG. 2, the proxy redirector 
of the present invention could be implemented through other means, using hardware, software, or a combinatwn of 
both. As an example, a level 4 switch having a fixed program to perform the required packet manipulations required 
by the present inventk)n couki be used. 

2S [0039] As described, the proxy cache returns requested objects to the address from which a request originated as 
indicated by the saddr and sport parameters in the IP header information, which is the address of the proxy redirector 
104 when the proxy cache is not connected on the network so that all responses do not automatically pass through 
the proxy redirector. The interactions between the requesting client and the proxy cache are transparent to both the 
client artd the proxy cache, since the client does not 'know" that its request is being redirected to the proxy by the 

30 proxy redirector, and the proxy cache, when receiving a GET request with an absolute URL does not know that that 
absolute URL is not being formulated by the client's browser operating in a non4ransparent rrKxie. Advantageously, 
the proxy cache requires no software modtficatkjns and standard proxy caches, connected anywhere on the network 
can be used in conjunction with the proxy redirector. If, however, the proxy is modified, using a programmable network 
element as prevkxjsly described, for example, the requested object retrieved by the proxy from its own cache or re- 

3S ceived from an origin sen/er, can be sent directly back to the client, thereby obviating the need to send such packets 
back to the proxy redirector for address translations arK* redtrectkxi to the client By performing only a half-NAT at the 
proxy redirector arKJ leaving the clients saddr an6 sport as the source IP address and port number in the header of 
the SYN packet, GET request packet(s), and other packets forwarded by proxy redirector 1 04 from the client, the proxy 
cache can return packets responsive to the request directly to the client by substituting the origin server's IP address 

40 and port number as the source address for its own address. If the proxy redirector performs a full NAT and PAT. then 
another mechanism must be incorporated to provkie the client address to the proxy cache, such as incorporating the 
client address information as part of an appendix to the absolute address in the nmdifled GET request and stripping 
the appertded client address informatkxi at the proxy before determining whether the requested object is stored in the 
cache or whether a connectkxi to the origin sender need be made. Advantageously, by sending the packets from the 

45 proxy cache directly back to the client, the delay encountered by transmitting such packets back to the proxy redirector 
for address translatk)n and redirection is eliminated. Disadvantageously, the proxy cache must be modified to perform 
these functions, precluding use of standard available proxy caches. 

[0040] Although described hereinabove in connecton with GET requests, the present inventton can equally be ap- 
plied to redirection of any type <rf request message in which the token is, for example, GET POST or HEAD, or any 

50 other type of token yet to be implemented andtor standardized. 

[0041] The foregoing therefore merely illustrates the principles of the inventbn. It will thus be appreciated that those 
skilled in the art will be able to devise various arrangements which, although not explk:itly described or shown herein, 
embody the principles of the inventk)n arKJ are included within its spirit and scope. Furthermore, all examples and 
conditbnal language recited hereinabove are principally interKled expressly to be only for pedagogical purposes to aid 

55 the reader in understarwJing the principles of the invention and the concepts contributed by the inventors to furthering 
the art, and are to be conslmed as being without limitation to such specifically recited examples and conditbns. More- 
over, all statements hereinabove reciting principles, aspects, and embodiments of the inventkxi, as well as specific 
examples thereof, are intended to encompass both structural and functional equivalents thereof. Additkwially, it is in- 
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tended that such equivalents include both cunentty known equivalents as well as equivalents developed in the future, 
i.e.. any elements developed that perfonm the same function, regardless of structure. 

[0042] Thus, for example, it will be appreciated by those skilled in the art that the block diagrams and ftowcharts 
described hereinabove represent conceptual views of illustrative circuitry and processes emtxxiying the principles of 

s the invantkxi . Similarly, it will be appreciated that any flowcharts, ftow diagrams, state transition diagrams, pseudocode, 
and the like represent various processes which may be substantially represented in computer readable medium and 
so executed by a computer or processor, whether or not such a computer or processor is explicitly shown. 
[0043] Jhe functions of the vark)us elements shown in the FIGS., including functional blocks labeled as "processors' 
may be provkied through the use of dedicated hardware as well as hardware capable of executing software in asso- 

10 ciatkm with appropriate software. When provided by a processor, the f unctbns may be provided by a single dedbated 
processor, by a single shared processor, or by a plurality of indivkiual processors, some of whk:h may be shared. 
Moreover, exploit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware 
capable of ^ecuting software, and may implicitly include, without limitatkxi, digital signal processor (DSP) hardware, 
read-only memory (ROM) for storing software, random access memory (RAM), and non^latile storage. Other hard- 

15 ware, corrventksnal arul/or custom, may also be included. Similarly, any switches shown in the FIGS, are conceptual 
only. Their functbn may be carried out through the operatkxi of program k>gk:. through dedicated logic, through the 
interactk>n of program control and dedk^ted k>gk:, or even manually, the particular technk^ue being selectable by the 
implementor as more specifically uralerstood from the context. 

[0044] In the daims hereof any element expressed as a means for performing a specified functbn is intended to 
20 encompass any way of performing that functk)n including, for example, a) a combination of circuit elements which 
performs that function or b) software in any form, including, therefore, firmware, mcrocode or the like, combined with 
appropriate circuitry for executing that software to perform the function. 



25 Claims 

1 . A method at a Layer 4 Switch for transparently redirecting an HTTP connection request that is directed to an origin 
server to a proxy cache over a packet-based computer network comprising the steps of: 

30 receiving at least one packet containing a request message within the HTTP connection, the at least one 

packet having an IP headercomprising a destination address of an origin server, the request message including 
a complete address of a specified object at the origin server; 

modifying the request message by combining the destination address of the origin sender with the complete 
35 address; and 

forwarding the at least one packet containing the modified request message to the proxy cache over the packet- 
based network. 

40 2. The method of claim 1 wfierein the step of modifying comprises the step of prefixing the complete address in the 
request message with the destinatkxt address of the origin server 

3. The method of claim 2 further comprising the step of: 

translating the destinatk)n address in an IP header of the at least one packet containing the modified request 
^ message to the address of the proxy cache. 

4. The method of claim 3 further comprising the step of: 

translating a source address in the IP header of the at least one packet containing the rtKxiified request 
message from an address of the client to an ackJress of the Layer 4 switch. 

so 

5. The method of claim 3 further comprising the step of: 

in a TCP header in packets received from the proxy cache commencing with an acknowledgment to the 
modified request message, modifying a value in a acknowledged byte sequence number field to reflect the in- 
creased number of bytes in the modified request message resulting from the step of prefixing the complete address 
S5 with the destinatkxi address of the origin sender. 

6. The method of claim 5 wherein the step of modifying the value in the acknowledged byte sequence number fiekJ 
comprises the step of decreasing the value in the acknowledged byte sequence number fiekt by the number of 
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bytes added by prefixing the destination address of the origin server to the complete address in the request mes- 
sage. 

7. The method of claim 6 further comprising the step of: 

translating in the IP header the destination address to the address of the client and the source address to 
that of the origin server in the packets received from the proxy cache commencing with the acknowledgment to 
the request message. 

a The method of claim 3 further comprising the step of: 

modify irtg a value in a sent byte sequertce numberfieW to reflect the increased number of bytes in the modified 
request message resulting from prefixing the complete address with the destination address of the origin server 
in a TOP header in packets received from the client folk>wing receipt of the request message. 

9. The metttod of claim 8 wherein the step of modifying the value in the sent byte sequence number fiekj comprises 
the step of increasing the value tn the sent byte sequerice number fieki by the number of bytes added by prefixing 
the destirtatkm address of the origin server to the complete address in the request message. 

10. The method of claim 9 further comprsing the step ct. 

translating the destinatkyi acfeiress to the address of the proxy cache in the IP header in each packet received 
from the client folbwing receipt of the request message. 

11 . The method of claim of claim 1 further comprising the step of selecting the proxy cache from a plurality of different 
proxy caches prior to receiving the at least one packet containing the request message. 

12. The method of claim 2 further comprising. prk>r to the step of receiving the at least one packet containing the 
request message, the steps of: 

receiving a packet from the proxy cache indk:ating a maximum segment size that packets sent to it thereafter 
should have; 

reducing by a predetermined number the maximum segment size of packets to be thereafter sent to the proxy 
cache; and 

sending a packet to the client indicating the reduced maximum segment size that packets thereafter sent by 
the client to the origin sender should have. 

13. The nnethod otf ctaim 12 wherein the predetermined number is equal at least to the maximum number of bytes 
added by the step of prefixing the destinatkxi address to the complete address in the request message. 

14. The method claim 1 3 further comprising the steps of: 

successively shifting to a next packet in the request message overflow bytes caused by the step of prefixing 
the destinatkxi address to the complete address in the request message, if the request message is contained 
within more than one packet; arKJ 

changing a length-of-packet pararr^ter in the IP header in a last packet of a multi-packet request message to 
reflect the bytes shifted into the last packet from a previous packet. 

15. The method of claim 13 further comprising the step of changing a length-of-packet parameter in the IP header to 
reflect the change in the length of that packet caused by the step of prefixing the destination address to th e complete 
address in the request message, if the request message is contained within one packet. 

16. The method of claim 1 wherein the request message is a GET request. 

17. The method ctaim 1 wherein the request message is a POST request. 

18. The method of claim 1 wherein the request message is a HEAD request. 
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19. A proxy redirector for transparently redirecting an HTTP connection request from a client that is directed to an 
origin server request message to a proxy cache over a packet-based computer network comprising means ar- 
ranged to carry out each step of a method as claimed in any d the preceding claims. 

20. The proxy redirector of daim 19 wherein the means for modifying the request message is a gateway program 
dyhamtcalty baded on a programmable network elenrrent. 

21 . A computer readable medium storing computer program instructions which are executable on a computer system 
implementing a Layer 4 switch for transparently redirecting an HTTP connection request from a client to a proxy 
cache over a packet-based computer network, sakJ computer program instructions comprising instructions defining 
the steps of a method as claimed in any of claims 1 to 18. 

22. A computer program product directly loadable into the internal memory of a computer system implementing a Layer 
4 switch, comprising software code portions for performing the steps of a method as clainrted in any of claims 1 to 
18 when sakJ product is run on such a computer system. 
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